Apparatus and method for a payment processing system for securing bankcard data

ABSTRACT

Apparatus and method for a payment processing system are described. The payment processing system provides security of and secures storage of bankcard data during storage in the payment processing system by encrypting the bankcard data.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is continuing application of application Ser. No.09/891,913, titled, “Method and Apparatus for A Payment Card System”,filed Jun. 26, 2001. The application Ser. No. 09/891,913 is incorporatedherein by reference.

The application is related to application Ser. No. 12/012,345, filedFeb. 1, 2008, and titled, “Security in use of Bankcards that ProtectsBankcard Data from Merchant Systems in a Payment Card System of TaraChand Singhal that claims priority from application Ser. No. 09/891,913.

FIELD OF THE INVENTION

The present invention is directed to a method and apparatus forfacilitating payment transactions to merchants using existing bankcardsand bank accounts of a customer. Further, the present invention isdirected to a method and apparatus for protecting the privacy andprivate data of a customer in data storage and during transactions.

BACKGROUND

People usually carry multiple types of bankcards. The multiple types ofbankcards can include charge cards, debit cards, check cards, andmerchant cards specific to a merchant. These types of bankcards havebecome very popular and a large number of people carry multipledifferent bankcards.

Unfortunately, existing bankcards are not entirely satisfactory, andhave a number of deficiencies. For example, existing bankcards sufferfrom ever changing security issues that the banking industry is alwaysworking to solve. Also, it is inconvenient for the customer to carrymultiple different bankcards. Existing bankcards have other additionaldeficiencies than those detailed herein.

SUMMARY

This invention is directed to a payment card that can be used by acustomer to perform a transaction with a merchant. In some of theembodiments provided herein, the payment card facilitates the use of anexisting bankcard of the customer to conduct a particular transaction.In some of the embodiments, the payment card provides a level ofsecurity to the customer because the payment card does not identify thecustomer. Further, the card number and/or the expiration date of thepayment card is not disclosed to the merchant.

The use of the payment card is facilitated by a payment system. Thepayment system allows the customer to open a payment card account. Inone of the embodiments provided herein, the payment system storesprivate data of the customer that is not directly recognizable andtraceable to the customer.

As used herein the term “bank card” shall mean and include charge cards,debit cards, and check cards issued by banks and/or other institutions,and merchant cards specific to a merchant. A number of alternate typesof bankcards are already in existence.

Further, as used herein, the term “privacy payment” shall mean andinclude a form of payment that does not specifically identify thecustomer to the merchant. For example, the privacy payment does notinclude and/or disclose the physical address, the social securitynumber, the electronic mail address, and/or information of the bankcardsof the customer to the merchant.

Moreover as used herein, the term “private data” shall mean and includedata that when taken alone can be used to specifically identify thecustomer. Private data can include the physical address, the socialsecurity number, the electronic mail address, the driver's licensenumber, and/or the information of the bankcards of the customer. Privatedata is also sometimes referred to as identifying data.

As provided herein, some embodiments of the present invention can allowthe customer to purchase one or more items or services from the merchantwithout the merchant knowing the identity, bankcard information and/oraddress of the customer. Stated another way, the payment system allowsthe customer to purchase one or more items or services from the merchantwithout disclosing the name, physical address, electronic mail address,and bankcard information of the customer to the merchant. As a resultthereof, the payment system minimizes the number of people, businessesand institutions that have access to the private data of the customer.This minimizes the opportunity for the private data of the customer tobe improperly disseminated.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features of this invention, as well as the invention itself,both as to its structure and its operation, will be best understood fromthe accompanying drawings, taken in conjunction with the accompanyingdescription, in which similar reference characters refer to similarparts, and in which:

FIG. 1A-1E is block diagrams that illustrate an apparatus and methodhaving features of the present invention;

FIG. 2 is a block diagram that illustrates a payment system havingfeatures of the present invention;

FIGS. 3A-3E are block diagrams that illustrate databases having featuresof the present invention;

FIG. 4A-4C illustrates a customer identifier having features of thepresent invention;

FIGS. 5A and 5B are simplified examples of web pages that can begenerated by the payment system; and

FIGS. 6A-6C and 7 are block diagrams that outline the operation of amethod and apparatus having features of the present invention.

DESCRIPTION Introduction

Referring initially to FIGS. 1A-1C, a method and apparatus 10 havingfeatures of the present invention can include a payment system 12, apayment system interface 12A, at least one customer interface 20A for acustomer 20, one or more merchant interfaces 22A (two are illustrated)for two merchants 22. In some of the embodiments, a payment card 30(illustrated in FIG. 1B) (i) facilitates the anonymous use of one ormore bankcards 31 (illustrated in FIG. 1C) of the customer 20 and (ii)provides anonymity and security to the customer 20 in transactionsbetween the customer 20 and the merchant 22.

As an overview, the present invention allows the customer 20 to maintainprivate data 25 (illustrated in FIG. 2) of the customer in the paymentsystem 12, and to use the payment card 30 in place of other bankcards 31of the customer. Preferred and optional aspects of the method andapparatus 10 are described below. The headings are provided for theconvenience of the reader.

Payment System 12

Referring to FIG. 2, the payment system 12 includes (i) a payment systemstorage device 26, (ii) a payment system operating system 27 stored inthe payment system storage device 26, (iii) a payment system program 28stored in the payment system storage device 26, (iv) and a paymentsystem processor 29 connected to the payment system storage device 26.

The payment system processor 29 can include one or more conventionalCPU's. The payment system processor 29 can be capable of high volumeprocessing and database searches.

The payment system storage device 26 can, for example, include one ormore magnetic disk drives, magnetic tape drives, optical storage units,CD-ROM drives and/or flash memory. The payment system storage device 26also contains a plurality of databases used in the processing oftransactions pursuant to the present invention. For example, asillustrated in FIG. 2, the payment system storage device 26 can includea merchant database 40, and a customer database 38. As outlined below,the customer database 38 can retain information regarding one or moreexisting bankcards 31 of the customer 20. The information can includethe customer name, the number for each bankcard 31, and/or theexpiration date of each bankcard 31.

Referring back to FIG. 1A, the payment system 12 includes a systemnetwork interface 12B that allows the payment system 12 to communicatewith the customer 20. Conventional internal or external modems may serveas the system network interface 12B. In one embodiment, the systemnetwork interface 12B is connected to the customer interface 20A on aglobal network 24. Alternately, the system network interface 12B can beconnected by an electronic, a voice and/or a traditional communicationsystem that allows the payment system 12 to interact with, the customerinterface 20A. For example, the payment system 12 can be connected tothe customer interface 20A with one or more phone lines.

The payment system interface 12A can include an input device (notshown), such as a keyboard, mouse or voice recognition software and adisplay that allows access to the payment system 12. As illustrated inFIGS. 1A, 1D and 1E, the payment system interface 12A interfaces with agateway 23, which interfaces with a bank card authorization network 21.The gateway 23 is a computer system that routs the data for paymentauthorization to the bank card authorization network 21, based on thebank routing number, usually the first 4 digits of the bankcard number.The bankcard authorization network 21 is computer systems that processdata from an existing bankcard 31. The bankcard authorization network 21receives the payment transaction data regarding the bankcard 31 andreturns payment authorization data. The gateway 23 and network 21 can besimilar to existing prior art devices used to process existingbankcards.

The payment system processor 29 is operative with the payment systemprogram 28 to perform the steps outlined in FIGS. 6A-6C and 7.

A customer network interface 20B allows the customer 20 to communicatewith the payment system 12 and/or the merchant 22. Conventional internalor external modems may serve as the customer network interface 20B. Inone embodiment, the customer network interface 20B is connected to themerchant interface 22A and the payment system interface 12A on theglobal network 24. Alternately, the customer network interface 20B canbe connected by other electronic, voice and/or traditional communicationsystems that allow the customer 20 to interact with the merchantinterface 22A and the payment system interface 12A.

The customer interface 20A can include an input device, such as akeyboard, mouse or voice recognition software and a display that allowsthe customer 20 to interact with the customer network interface 20B.

A merchant network interface 22B allows the merchant 22 to communicatewith the gateway 23. Conventional internal or external modems may serveas the merchant network interface 22B. The merchant network interface22B can be connected to the customer interface 20A on the global network24. Alternately, the merchant network interface 22B can be connected byother electronic, voice and/or traditional communication systems thatallow the merchant 22 to interact with the gateway 23.

The merchant system interface 22A can include an input device, such as akeyboard, mouse or voice recognition software and a display that allowsaccess to the gateway 23.

Payment Card 30

With reference to FIG. 1B, the payment card 30 has front side 30A andback side 30B. The front side 30A can include the name of the card 32A,and the customer name 32B. The customer name 32B can be a chosen alias354B of the customer as described later with reference to FIGS. 3D and5B. The back side 30B can include a machine readable area 33 such as amagnetic strip. The magnetic strip can include data in an encoded form.The data can include a customer identifier 320. One form of the customeridentifier 320 is described later with reference to FIG. 4C.

In some of the embodiments, the information and data contained in themagnetic strip does not contain any of the private data 25 of thecustomer such as the name, the customer address, the card number(s) ofthe existing bank cards 31 of the customer 20 and/or the expiration dateof the existing bank cards 31 of the customer 20. With this design, ifthe payment card 30 fell into wrong hands, it does not identify the nameof the customer and the existing bank card(s) of the customer 20.

Bank Card 31

FIG. 1C illustrates a bankcard 31 that can be used in conjunction withthe present invention. The bankcard 31 can be a debit card, a creditcard, a check card, or another type of card already obtained by thecustomer. The bank card 31 can include private data 25 of the customer20 including the name, number of the bank card, expiration date of thebank card 31 and signature as illustrated on front and back sides 31Aand 31B of the bank card 31.

Payment Card 30 Usage

With reference to FIG. 1D, when the customer 20 is using the paymentcard 30 at the location of the merchant 22, the payment card 30 can beswiped in a card reader 34 that is at the location of the merchant 22.The card reader 34 is adapted to read the readable area 33 of thepayment card 30. The card reader 34 can include a display window 34A, acard slide slot 34B, function buttons 34C that enables the selection ofone of the bank cards, a numeric keypad 34D, an enter button 34E andYes/No button 34F. Subsequently, the customer 20 uses the buttons 34C toselect the type of transaction and enters a PIN number using the numerickeypad 34D. The merchant interface 22A generates a merchant identifierand a total payment amount for the transaction. The merchant identifiercan be any combination of characters that identifies the merchant 22.The total payment amount for the transaction will vary according to thetransaction. The transaction can be for one or more purchased item(s)and/or services from the merchant.

Next, the data from the payment card 30, the merchant identifier andpayment amount is then sent to the gateway 23 using the merchant networkinterface 22B. In this embodiment, the gateway 23 is adapted torecognize and/or identify the payment card 30 relative to otherbankcards 31. When the gateway 23 detects that the payment card 30 isbeing used, the gateway 23 connects to and sends the payment card numberand PIN data to the payment system 12 and waits for the payment system12 to send the customer name, the number of the bank card and theexpiration date of the bank card 31 from the payment system 12 to thegateway 23. The adapted gateway 23 then reassembles the paymenttransaction data of name, the bankcard number, expiration date, merchantidentifier and amount and sends that to the bankcard authorizationnetwork 21. The bankcard authorization network 21 uses this informationto determine if the bankcard is good to cover the transaction. Ifacceptable the authorization network 21 provides a payment authorizationnumber that is forwarded to the merchant via the gateway 23.Additionally, the bankcard of the customer is charged or debited by theauthorization network 21.

Alternately, referring to FIG. 1D, the customer 20 can use the paymentcard 30 to make a transaction in a location, away from the merchantusing the World Wide Web. In this version, the customer 20, instead ofbeing physically at the location of the merchant 22, is making a paymentthrough a merchant web page 36, that displays the merchant identifier36A, the payment amount 36B, a space for entry of card number 36C of thepayment card 30, the expiration data 36D of the payment card 30, thename 36E of the customer and the e-mail address 36F of the customer. Thecustomer 20 enters the payment card 30 data such as card number,expiration date, name and e-mail. Some of the data to be entered here isillustrated later with reference to FIG. 4B.

Subsequently, the information is transferred to the gateway 23. When thegateway 23 receives the connection and data from the merchant web page36, the adapted gateway 23 detects the use of the payment card 30 andforwards the data to the payment system 12. The payment system 12, usingthe data received via the gateway 23, searches the payment systemdatabases 38A-38D (illustrated in FIG. 2), and assembles the pieces of apayment transaction including customer name, the number of the bankcard, the expiration date of the bank card, and forwards that to gateway23, which completes the assembly of payment transaction record alongwith merchant identifier and amount forwards to the bank cardauthorization network 21. The bankcard authorization network 21processes a payment from one of the bankcards 31 of the customer andgenerates a payment authorization number. For each payment transaction,the gateway 23 or the merchant interface 22A generates a referencenumber. The reference number is used to reference a particular paymentfrom other payments processed through the gateway 23 and theauthorization network 21. On payment approval, the reference number, anda payment authorization number are returned to the merchant interface22A. The reference number and the payment authorization number is a“privacy payment” that does not identify the customer to the merchant.

The card authorization network 21 cannot distinguish this paymenttransaction from any other card payment transaction it may receivedirectly from the gateway 23. The card authorization network 21processes the transaction and responds with the payment authorizationand reference number for the transaction. On receiving the paymentauthorization number, the gateway 23 forwards the information to themerchant 22. Additionally, the bankcard of the customer is charged ordebited by the authorization network 21.

FIG. 1E illustrates an alternative way to conduct a transaction usingthe payment card 30. In this alternative embodiment, the paymenttransaction data is directly received by the payment system 12 with thehelp of a wireless network without it first going to the gateway 23. Thepayment system 12, with this payment data, is able to assemble thecomplete payment data of the customer including the customer name, bankcard number, expiration date, and amount and merchant identifier andforward that to the gateway 23, which in turn forwards it to theauthorization network 21. In this embodiment, the gateway 23 need not beadapted to recognize a payment card.

Further, in this embodiment, a merchant computer system 100, a wirelessdata input device 104 and a docking station 102, can be utilized. Thedocking station 102 is used to charge the device 104 and to transferdata 102A between the input device 104 and the merchant computer system100. The input device 104 can include privacy shields 106 that arehinged to the left and/or right sides of the device 104. The shields 106may be folded when the device 104 is put in the docking station 102. Theshields 106 may be unfolded when used by the customer 20.

The device 104 can include a display screen 104A, a keypad 104B, a cardreader mechanism 104C and antenna 104D. The device 104 can includememory for storing details of multiple transactions (not shown). Thedevice 104 may also have a printing mechanism (not shown).

The merchant 22 can pre-program the device 104 with the merchantidentifier 51 that enables the payment system 12 to identify themerchant. The merchant, at the time of a payment transaction with thecustomer, may remove the device 104 from the docking station 102, enterthe dollar amount of the transaction using keypad 104B and displayscreen 104A, and then transfer the device 104 to the customer 20.

The device 104 enables the customer 20, to review the dollar amount ofthe transaction and to swipe the payment card 30 and then enter apersonal identification number in the device 104. The device 104forwards the customer data and merchant data as a data block 122 to thepayment system 12 using a wireless cellular network 130.

The payment system 12, using the customer data and merchant data, asdescribed elsewhere in this application, runs a credit card transactionusing the gateway 23 and the payment network 21 and returns thereference number and the payment authorization number for thistransaction 124 to the device 104. The customer reviews theauthorization. The device 104 can include a printer (not shown) forprinting a confirmation slip that lists the date, the merchant, thedollar amount and/or the reference number. The customer subsequentlytransfers the device 104 to the merchant. The merchant may return thedevice 104 back to the docking station 102 or use the device 104 foranother transaction with another customer. The docking station 102 readsthe payment data of each transaction from the device 104 by thetransaction's date/time, reference numbers and authorization numbers,dollar amount 120 and transfers the data to the merchant computer system100.

System Program 28

The payment system program 28 is operative with the payment systemprocessor 29 to provide the functions of (i) interfacing with thecustomer 20 to receive and save customer private data 25 in databases38A-38D via web pages 500A-500B, (ii) interface with the gateway 23 toreceive payment transaction data from the merchant 22, (iii) processpayment transaction data by searching databases 38A-38D to assemble anexisting card payment transaction data, and (iv) to interface with thecard networks 21 to send the transaction data and receive paymentauthorization number and a reference number. Further, the system program28 is operated with the payment system processor 29 to perform the tasksof the payment system 12 provided herein.

Customer Database 38

With reference to FIG. 2, the customer database 38 within the paymentsystem 12 contains private data 25 specifically related to the customer20 that is transferred to the privacy system 12 from the customer. Theprivate data 25 related to the customer 20 can be separated and storedin at least four separate sub-databases, namely, (i) an identifiersub-database 38A, (ii) identifying data sub-database 38B, (iii) existingbank card data sub-database 38C, and (iv) payment card PIN datasub-database 38D of each customer 20. The sub-databases are explainedbelow.

Identifier Database 38A

Referring to FIGS. 2 and 3A, the payment system 12 can store a customeridentifier 320 for each of the customers 20 in the identifier database38A. As provided herein, the customer identifier 320 can be used toanonymously identify and verify the customer 20 for gaining access toand interacting with the payment system 12. The customer identifier 320enables the customer 20 to interact with and use the payment system 12without revealing private data of the customer. Stated another way, thecustomer identifier 320 enables the customer 20 to be anonymouslyidentified to the payment system 12.

The customer identifier 320 can be any number of characters that can beused to identify and verify the customer 20 for gaining access to andinteracting with the payment system 12. The customer identifier 320 canbe self-created by the customer 20. More specifically, the customer 20can create the exact characters that make up the customer identifier 320without the aid or authority of any business, the payment system 12 orgovernment entity. However, as provided herein, the payment system 12can provide a guideline for the format of the customer identifier 320.The details of the customer identifier 320 are explained in more detailbelow.

The payment system 12 can also assign and associate a unique sequencenumber 330 for each customer identifier 320. The sequence number 330 caninclude any number of characters. The sequence number 330 issubsequently used as a reference to save and retrieve the private data25 of the customer 20 in the identifying database 38B, existing bankcarddata database 38C and payment card data database 38D. The sequencenumber 330 can also be stored with the customer identifier 320 in theidentifier database 38A.

The customer 20 can access the payment system 12 using the customernetwork interface 20B. Upon the entry of the customer identifier 320 bythe customer 20 via the customer interface 20A, the payment systemprogram 28 operates with the payment system processor 29 to review theidentifier database 38A to check for the existence of the customeridentifier 320. Upon the location of an existing customer identifier320, the payment system 12 allows the customer 20 to have access to theprivate data 25 that is tied to the customer identifier 320. Theidentifier database 38A is also used to store the new customeridentifier 320 for each new customer 20 that creates a new customeridentifier 320.

Identifying Database 38B

Referring to FIG. 3B, the payment system 12 can store any identifyingdata 322 of the customer 20 in the identifying database 38B of thestorage device 26. Identifying data 322, as used herein, shall mean anyinformation or data of the customer 20 that if used independently issufficient to positively identify the customer 20 to a third party.Examples of identifying data 322 can include, a name, an address, atelephone number, a facsimile number, an e-mail address, a socialsecurity number, credit card number, and/or a driver license number ofthe customer 20.

The identifying data 322 can be kept in the identifying database 38B ofthe payment system 12 in a manner that safeguards the privacy of theidentifying data 322 in the storage device. Many approaches may be usedto safeguard the privacy of identifying data 322. For example, access tothe identifying database 38B can be controlled by a password (notshown).

The present invention also discloses a method that may be used inconjunction with and/or separately from any other methods to make theidentifying data 322 stored in the identifying database 38B more secure.This method uses separate databases for each piece of the data. As asimplified illustration, referring to FIG. 3B, the name 350A, streetaddress 350B, city/state/zip address 350C, e-mail address 350D, andtelephone number 350E of the customer may be kept in physically separatedatabases 322A to 322E respectively. The data pieces within the separatesub-databases are referenced to the customer by the sequence number 330and are accessible by using the sequence number 330. In this method, theidentifying data of the customer is fragmented over many databases andstorage devices, such that one database only stores partial informationof the customer.

Existing Bank Card Data Database 38C

With reference to FIG. 3C, the information and data relating to theexisting bankcards 31 of the customer 20 can be stored as multiplepartial card data in multiple databases of the payment system. As asimplified illustration, for each bankcard 31, the customer name isstored as data 322A in database 38B (illustrated in FIG. 3B) and thecard number and card expiration as data 324A and 324B in database 38C.The database 324A may store card numbers 352A. The data relating to themultiple bankcards of the customer can be stored and anchored bysequence number 330. Database 324B can store for each of the bank cards,its corresponding expiration date 352B and for those bank cards forwhich a PIN is used, the PIN of the bank card 352C.

Existing Card Data Security Methods

To provide yet another level of security, for each bankcard 31, the cardnumber and the expiration date may be partitioned, as partial dataelements into separate databases. There are many methods of creatingpartial data elements, some of them are described herein. The details ofbreaking the data into partial data elements and then reconstructing theoriginal data from the partial data elements are exclusively embedded inthe logic of the payment system program which stores and retrieves thedata and is not part of the data itself. This provides a level ofsecurity to the data of the bankcard that is stored in the paymentsystem. Some examples of logic that may be used in creating partial dataelements are described as follows:

Method 1: partial data elements are 16 digits of the card number andexpiration date of the bankcards.

Method 2: partial data elements are the first 4 digits of the 16 digitsof the card number and remainder 12 digits added to the 4 digits of theexpiration date.

Method 3: partial data elements are the first 8 digits of the 16 digitsof the card number and the remainder 8 digits added to the 4 digits ofthe expiration date.

Method 4: partial data elements are five sequences of four 4-digits ofthe 16 digits of the card number and 4 digits of the expiration date.

Method 5: partial data elements are five sequences of four 4-digits ofthe 16 digits of the card number and 4-digits of the expiration date.Wherein the five sequences are stored in a random order, the order ofrandomness being part of data storage and data retrieval logic.

Method 6: partial data elements are five sequences of four 4-digits ofthe 16 digits of the card number and 4-digits of the expiration date.Wherein any one 4-digit number, selected in a random order is offset byan offset number, the random order and offset number being part of datastorage and data retrieval logic.

Method 7: Any permutation or combination of the methods 1 to 6 discussedabove.

One of the data security methods described above is illustrated with asimplified illustration in FIG. 3E. The number 352A of the bankcard isreferenced by the sequence number 330. As detailed below, the originalinformation is transferred into equivalent information that isindistinguishable in format to the original information. To beindistinguishable, for example, (i) numbers in the original informationare replaced with alternate numbers in the equivalent information, and(ii) letters in the original information are replaced with alternateletters in the equivalent information. The bankcard number 352A isbroken into four original elements A, B, C and D. The element A is abank code that identifies the bank that issued the bankcard. Theexpiration date 352B is called original element E.

A transformation logic 310 within the system program 28 is used totransform the bankcard data 352A and 352B into equivalent data elements314 for storage. The transformation logic 310 takes the originalbankcard data elements and transforms the data into an equivalentbankcard data elements that is indistinguishable from the originalbankcard data in format. Subsequently, the equivalent data elements arestored in the payment system.

This method of data storage obviates the need and expense forextra-ordinary measures to secure and safeguard the databases. Thetransformation logic 310 is the only knowledge that needs to beprotected. The transformation logic 310 is only known to the creators ofthe logic design and is further stored in the computer system ascomplied code, and thus not accessible for theft directly from thecomputer system.

The transformation logic 310 has a forward transform logic 310A, areverse transform logic 310B, a bank code table 310C listing all thepossible bank codes, an expiration date table 310D, listing all thepossible expiration dates and an offset table 310E, listing the offsetsthat are applied to the elements A, B, C, D, and E for a range ofsequence numbers.

For a bankcard data that is input to the logic 310, the forwardtransform logic 310A, determines the range of the sequence number. Thenusing this range it reads the offsets for that range from table 310E.Offset 1 is applied to original element A to get equivalent element A,offset 2 is applied to original element B to get equivalent element B,offset 3 is applied to original element C to get equivalent element C,offset 4 is applied to original element D to get equivalent element Dand offset 5 is applied to original element E to get equivalent elementE.

These offsets can be of many types. For example, the offsets for elementA and E enable an equivalent bank code and expiration date from thetables 310C and 310D. Offsets for element B, C and D provide a means fornew equivalent elements B, C and D.

The reverse transform logic 310B, using the sequence number 330 as aninput parameter, enables the equivalent bank card data 314 to beconverted back to the original bank card data of 352A and 352B.

It is believed, using this type of transformation logic, there is nocorrelation between the equivalent bankcard data and the originalbankcard data, such that a thief or hacker cannot determine the originalbankcard data. It obviates the need for extra-ordinary measures tosafeguard the bankcard databases.

Payment Card Data Database 38D

With reference to FIG. 3D, the data of the payment card 30 of thecustomers 20 can be stored within two databases 326A and 326B. Thedatabase 326A may store PIN numbers 354A for each bank card 31 indatabase 324A that have been self-selected by the customer 20. Thesequence number 330 anchors the PIN data of each customer. Database 326Bmay store for each customer the self-selected alias name 354B of thecustomer. The sequence number 330 also anchors the alias name data 326Bof the customer.

Customer Identifier

FIG. 4A illustrates one embodiment of a customer identifier 320. Thecustomer identifier 320 illustrated in FIG. 4 utilizes a single datastring 400 that can be used to anonymously verify the customer 20 to thepayment system 12. Because there is no public identification step, theidentity of the customer 20 can be maintained within the payment system12 without formally and publicly identifying the customer 20 to thepayment system 12. Further, the customers 20 can access the paymentsystem 12 without personally identifying themselves to the paymentsystem 12.

The anonymous identifier 320 can include one or more elements 408, 410,412, 414, 416 that are separated by a delimiter 404. The elements408-416 make it easy for the customer 20 to create, use and remember theanonymous identifier 320. Each of the elements 408-416, for example, caninclude one or more easy to remember characters.

As provided herein, a first element 408 can include the sub-elements ofa calendar date. A second element 410 may be a class code of thecustomer 20. A third element 412 may be in the form of a location codeof the customer 20. A fourth element 414 may be a name abbreviation ofthe customer 20. A fifth element 416 can be a sequence code.

Any combination and/or organization of one or more of the elements408-416 as described above may be used as the customer identifier 320.The customer identifier 320 can be self-created by the customer 20 thefirst time the customer 20 interacts with the payment system 12. Afterthe customer identifier 320 is created, it can be stored in theidentifier database 38A by the payment system 12. Subsequently, thecustomer identifier 320 is used to verify the customer 20 to the paymentsystem 12 so that the customer has access to the private data 25 of thecustomer in the payment system 12.

FIG. 4B illustrates a form of the customer identifier 320 that may beused for a web based payment transaction, where the card number,expiration date, and name need to be provided. It may also be used wherethe customer 20 has established a voice communication with an employeeof the merchant to process the payment transaction. A sixteen digitpayment card number 418 is provided. This card number has the customeridentifier 320 that includes elements of date 408, personal code 410,zip code 412, and name initials 414 as one continuous string. A cardexpiration date string 420 of 4 digits may be provided. This string 420may be the payment card PIN 354A that identifies the particular existingbankcard the customer may choose for this transaction. For the name, thecustomer may provide an alias name 354B. The payment card PIN 354A andalias name 354B are illustrated in FIGS. 3D and 5B.

FIG. 4C illustrates a form of customer identifier 320 that may be storedin the readable area 33 of the payment card 30. The customer identifieris encoded 422 and the code number 424 used for encoding is embedded byappending it as part of the encoded customer identifier.

Referring to FIG. 3D, the payment card database 38D maintains theencoding data 326C as data items code number 354C and the code algorithm354D. When a transaction using the card 30 is received at the paymentsystem 12 via the gateway 23, the corresponding algorithm is retrievedfrom database 326C to decode the customer identifier. This can provide alevel of security to the customer, if the card 30 falls in thepossession of a dishonest person.

Merchant Database 40

The merchant database 40 maintains data on all of the merchants 22 thatinteract with the payment system 12. The merchant database 40 can store(i) a merchant identifier 51 and (ii) the merchant date 40A, e.g. thename, address, phone, facsimile, web page, and/or electronic mailaddress of the merchant together in one sub-database. A merchant 22 mayconnect to payment system 12 and enter/update merchant data. In one ofthe embodiments, the merchant database 40 may be used to verify that themerchant identifier 51 is correct when the payment system 12 receivesthe payment transaction data from the merchant 22. It may also be usedfor billing purposes if a merchant is charged fees for interfacing withthe payment system 12. Additionally, the merchant database 40 may beused to keep payment transaction data such as merchant identifier,reference number, authorization number, date, time, and amount forarchival enabling later retrieval and or reference by the merchant.

Payment System Web Pages 500

In an optional version of the present invention, the payment systemprogram 28 is operative with the payment system processor 29 to generateone or more web pages 500A on the World Wide Web. The web pages 500Aallow each customer 20 to provide information through the customerinterface 20A to the payment system 12. Alternately, for example,instead of the World Wide Web, the customer 20 can provide some or allof the information to the payment system 12 via voice mail, facsimile,or postal mail transmissions.

FIG. 5A illustrates an example of an initial payment system web page500A. The initial system web page 500A can be displayed on the customerinterface 20A when the customer 20 first registers with the paymentsystem.

The initial payment system web page 500A illustrated in FIG. 5A includes(i) an area for entry of the customer identifier 320, including areasfor entering the data element 408, the personal element 410, thelocation element 412, the name element 414 and the number element 416 ofthe customer identifier 320 of the customer 20 and (ii) a SEND icon 514.

After the customer 20 enters the required information and clicks theSEND icon 514, the payment system 12 receives and validates the customeridentifier 320. Subsequently, the payment system 12 generates a datatype page 536 that allows the customer 20 to select data type toenter/retrieve 522 from (i) identifying data 322, (ii) existing bankcard data 324 and payment card data 326. After selection of a data typeand clicking SEND icon 534, a data web page 500B with the correspondingdata type forms 524A, 524B and 524C, are displayed. FIG. 5B illustratesa data web page 500B for entering customer private data 25. Form 524A onthe web page allows entry of identifying data 322A-E such as name 350A,address 350B, city/state/zip 350C, telephone 350D and e-mail address350E. Form 524B on the web page allows entry of existing bank card data324A-C such as card number 352A, card expiration date 352B and a bankPIN 352C, if required for the specific bank card. Form 524C allows entryof payment card PIN 354A and alias name 354B. The payment card PIN 354Ais created and entered for each of the existing card numbers 352A of thecustomer and enables the customer to select any one of the existingcards when conducting a payment transaction using the payment card.

Operation

The operation of the apparatus 10 and payment system 12 for a paymenttransaction can be further understood with reference to the flow chartsillustrated in FIGS. 6A-7. The operation of the payment card inprocessing a payment transaction can be better understood with referenceto FIGS. 6A, 6B and 6C. The method for the customer 20 to establish anaccount with the payment system 12 is illustrated in FIG. 7.Importantly, the order of some or all of the steps can be varied.Further, not all of the steps outlined below are necessary to perform atransaction pursuant to the present invention.

More specifically, FIG. 6A outlines the steps for using the paymentsystem 12 when the customer is at the location of the merchant.Referring initially to FIG. 6A, at step 600, the customer 20 is at thesite of the merchant 22, ready to make a payment. At step 602, thecustomer selects the type of bankcard using the reader as a debit cardbecause a debit card requires entry of PIN to complete the transaction.At step 604 the customer swipes the payment card through the reader. Atstep 606, the card reader logic reads the payment card number. At step608, the logic prompts the customer for a PIN number. At step 610, thecustomer enters the PIN specific to one of the bankcards that thecustomer wishes to use for this particular payment. At step 612, thelogic sends the payment card number, PIN, dollar amount that has beenentered by the merchant, and the merchant identifier to the adaptedgateway 23. At step 614, the adapted gateway detects the use of apayment card and forwards data to the payment system 12. At step 616,the payment system 12 receives this data, decodes the card number, findsthe sequence number. At step 618, the payment system uses the sequencenumber to get and verify the PIN.

At step 620, the payment system assembles the specific card data for oneof the bankcards of the customer 20, as identified by the PIN and sendsthat data to the adapted gateway 23. The card data can include the name,card number, expiration date. The adapted gateway using that data andmerchant identifier and the amount, forwards the information to the cardnetwork 21. At step 622, the card network 21 processes the transactionand returns an authorization number to the gateway 23. At step 624, thegateway 23 forwards the authorization number to the merchant system. Atstep 626, the card reader displays that the transaction is approved.

FIG. 6B outlines the steps for using the payment system when thecustomer is at a location away from that of the merchant. With referenceto FIG. 6B, at step 630, the customer is ready to make a payment. Atstep 632, the customer has shopped at the web page of the merchantand/or viewed a catalog of the merchant and enters the 16-digit cardnumber of the payment card on the merchant web page or conveys it on avoice telephone to the merchant. At step 634, the customer enters4-digit expiration date field as 4 digit PIN or conveys it on voicetelephone to the employee of the merchant. At step 636, the customer 20enters the name and e-mail address on web page or conveys it on voicetelephone to the employee of the merchant. At step 638, the Merchant orweb logic sends the payment card number, pin, amount and merchantidentifier to the gateway. At step 640, the adapted gateway 23 detectsthe use of a payment card 30 and forwards data to the payment system 12.At step 642, the payment system receives the data, the payment cardnumber, and finds the sequence number. At step 644, the payment systemuses the sequence number to get and verify the PIN number. At step 646,the payment system 12 assembles specific card data of name, card number,expiration date, and sends the information to the adapted gateway 23,which assembles the complete payment transaction data including merchantidentifier and payment amount and forwards the information to bankcardauthorization network 21. At step 648, the adapted gateway 23 waits andreceives the authorization number and at step 650, forwards theauthorization number to the merchant system 22A. At step 652, the weblogic displays card approved.

FIG. 6C outlines alternate steps for using the payment system 12 whenthe customer is at the location of the merchant. In this embodiment, byusing a wireless network the merchant interfaces directly with thepayment system 12 and bypassing the gateway 23. Hence, the gateway 23need not be adapted to recognize a payment card number in thisembodiment. Here, the payment system assembles a complete paymenttransaction data and forwards the information to the gateway 23 to beforwarded to network 21. Alternatively the payment system may directlyconnect to the network 21, bypassing the prior art gateway 23 entirely.

Referring to FIG. 6C, at step 660, the customer is at the site of themerchant 22 and ready to conduct a transaction. At step 662, theMerchant removes the wireless device 104 from the docking station 102and enters the dollar amount of the transaction into the device 104 andhands the device 104 to the customer 20. At step 664, the customerreviews the dollar amount and swipes the payment card. At step 666, thedevice 104 logic reads the card number. At step 668, the logic promptsfor a card PIN. At step 670 the customer enters a PIN specific to abankcard. At step 672 the logic sends the payment card number, PIN,amount and merchant identifier to the payment system 12 via the cellularnetwork. At step 674, the payment system 12 receives the data, decodesthe payment card number, and finds the sequence number. At step 676, thepayment system, with the sequence number, verifies the PIN andidentifies the specific bankcard. At step 678, the payment systemassembles the specific card data of name, card number, expiration date,merchant identifier and amount and sends the data to payment network 21.At step 680, the payment system waits/receives the authorization number.At step 682 the payment system saves the authorization number andforwards the data to the device 104. At step 684, the merchant 22, usingthe docking station, transfers data from the device 104 to the merchantsystem 100.

One method used by the customer 20 to establish an account with thepayment system 12 is illustrated in FIG. 7. At step 702, the customerselects to connect to the payment system 12. At step 704, the paymentsystem web page 500A is displayed. At step 706, the customerenters/creates the customer identifier and submits the customeridentifier. At step 708, the payment system checks for the existence ofthe customer identifier in the identifier database 38A and sendsvalidation by displaying data screen 536. At step 710, the customerselects “enter identifying data”. At step 712, the payment systemdisplays identifying data form 524A. At step 714, the customer entersidentifying data and selects SEND. At step 716, the payment system doesoptional address verification from the United States Postal Servicedatabase and then saves the identifying data in the identifying-database38B. At step 718, the customer selects existing card data. At step 720,the payment system displays existing card data form 524B. At step 722,the customer enters existing card data and selects SEND. At step 724,the payment system checks existing bankcard data and saves the existingbankcard data in database 38C. The checking of existing bankcard datamay include checking for correct format and optionally may also includechecking for stolen and duplicate data by connecting to the bankcardauthorization network 21. At step 726, the customer selects payment carddata. At step 728, the payment system displays payment card data form524C. At step 730, the customer enters payment card PIN data 554A foreach of the existing cards and alias name 354B and selects SEND. At step732, the payment system saves PIN data and alias name in database 38D.At step 734, the payment system notifies the customer that the cardaccount has been established and a payment card will be mailed to thecustomer. This notification can be by e-mail, U.S. mail or a sign offmessage on the web page 500A. At step 736, the payment system creates apayment card 30 and mails it to the customer 20.

In summary, the payment system 12 allows the customer 20 to maintain onepayment card 30 that can be used to facilitate the anonymous use of theother existing bankcards 31 of the customer. The payment system canstore the private data 25 of the customer anonymously by separating thedata elements in separate databases. The customer can conduct atransaction and receive a service or product from the merchant 22without disclosing the name, address, private data and credit cardinformation of the customer 20 to the merchant 22. The payment system 12minimizes the number of people, businesses and institutions that haveaccess to the private information of the customer 20. This minimizes theopportunity for the private information of the customer 20 to beimproperly disseminated.

While the particular apparatus 10 and method as illustrated herein anddisclosed in detail is fully capable of obtaining the objects andproviding the advantages herein before stated, it is to be understoodthat it is merely illustrative of the presently preferred embodiments ofthe invention and that no limitations are intended to the details ofconstruction or design herein shown other than as described in theappended claims.

1. A method of securing storage of bankcard data in a payment processingcomputer system, comprising the steps of: a. transforming by a centralprocessing unit of the computer system hosting a system program anoriginal bankcard data, received into a temporary memory of the systemusing a forward transform logic, into an encrypted bankcard data; b.creating a sequence number as a unique reference number by the systemprogram using the central processing unit of the computer system forthis original bankcard data; b. storing in a storage by the systemprogram using the central processing unit of the computer system onlythe encrypted bankcard data referenced by the sequence number.
 2. Themethod as in claim 1, comprising the steps of: using the sequence numberby the system program for retrieval of the encrypted bankcard data fromthe storage.
 3. The method as in claim 2, comprising the steps of:transforming using a reverse transform function, the encrypted bankcarddata into the original bankcard data.
 4. The method as in claim 3,comprising the steps of: using by the system program the originalbankcard data for transaction processing.
 5. The method as in claim 4,comprising the steps of: not storing by the system program from thememory the original bankcard data after completion of the transactionprocessing.
 6. The method as in claim 1, comprising the steps of:storing by the system program the encrypted bankcard data in a storagesystem that is separate from a computer system that stores merchantdata.
 7. A system for securing storage of bankcard data in a paymentprocessing computer system, comprising: a. a central processing unit ofa computer system hosting a system program transforms an originalbankcard data, received into a temporary memory of the system using aforward transform logic, into an encrypted bankcard data; b. the centralprocessing unit of the computer system using the system program createsa sequence number as a unique reference number for this originalbankcard data; c. the central processing unit of the computer systemusing the system program stores in a storage only the encrypted bankcarddata referenced by the sequence number.
 8. The system as in claim 7,comprising: the system program uses the sequence number for retrieval ofthe encrypted bankcard data from the storage.
 9. The system as in claim8, comprising: the system program transforms using a reverse transformlogic, the encrypted bankcard data into the original bankcard data. 10.The system as in claim 9, comprising: the system program uses theoriginal bankcard data for transaction processing.
 11. The system as inclaim 10, comprising the steps of: the system program does not storefrom a memory the original bankcard data after completion of thetransaction processing.
 12. The system as in claim 7, comprising: thesystem program stores encrypted bankcard data in a storage system thatis separate from a computer system that stores merchant data.